-
Notifications
You must be signed in to change notification settings - Fork 243
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fetch-metadata: remove tokio #1822
Conversation
@@ -29,6 +29,7 @@ quote = { workspace = true } | |||
subxt-codegen = { workspace = true, features = ["fetch-metadata"] } | |||
scale-typegen = { workspace = true } | |||
polkadot-sdk = { workspace = true, optional = true, features = ["sp-io", "sc-executor-common", "sp-state-machine", "sp-maybe-compressed-blob", "sc-executor"] } | |||
futures = { workspace = true, features = ["executor"] } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess one reason for tokio
was just that it was already likely to be included as a dep. I wonder if this adds any new deps to the tree or whether it was also in use somewhere anyways?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EDIT: It will bring in futures-executor/futures-task
which is small and it should be much more lite-weight than tokio rt and it compiles for WASM
If one brings in futures with the default features this is already enabled and most likely already enabled for most cases I think...
after thinking about this, if one doesn't use tokio then creating jsonrpsee::ws_client this will panic so I think it safer to keep tokio anyway |
I don't think it's worth to use tokio in fetch-metadata for the blocking API and I removed in favor if futures::executor::block_on